Modifying the default link activation
As noted, the single toolbar correctly changes its state to reflect which page is the active page. When the window first comes up, the Update buttons are disabled because there is no updateable object on that page. When you select Page 2, 3, or 4, the buttons are enabled.
However, if you select Page 1 again, the buttons remain enabled, which is not correct. This happens because of the setting of the toolbar property DeactivateTargetOnHide. Navigation and TableIO links must be adjusted when the page changes and there is more than one target for the link. These links cannot support more than one active target at a time, since the toolbar must reflect the state of a single object. The DeactivateTargetOnHide property determines how the toolbar handles that adjustment. By default, the property value is FALSE, so when a page containing a TableIO or Navigation target for a toolbar is hidden by a page change operation, the toolbar waits until another page with an object that uses the same link is viewed before re-evaluating the state of the buttons. If every page in the folder has a TableIO link, then as each new page is viewed, the toolbar resets its button state for each new target. In this case the default behavior works fine.
But if there is a page with no TableIO-Target for the toolbar, then nothing happens when the user selects that page, and the state remains set to what it was for the previously selected page. This is normally not appropriate.
In this case you must set the DeactivateTargetOnHide property to TRUE so that the toolbar resets its buttons immediately when a page is hidden. In this way, they remain disabled when the user selects Page 1 after Page 2 because there is no TableIO-Target on Page 1. The downside of this, and the reason why this is not the default behavior, is that this can result in some flashing as the buttons are disabled when one page is hidden and then (perhaps) immediately re-enabled when the next page is viewed.
When you add a toolbar to a static window, there is a custom property sheet, shown in Figure 3–1, that you can access through the AppBuilder and where you can set the property.
.
For dynamic windows, you can bring up the dynamic property sheet, shown in Figure 3–2, for the toolbar in the Container Builder and set the property there.
After you do this, the Update buttons are always enabled when you select Page 1.
To clarify something about this behavior, bring up your test window and select Page 2. The Customer Maintenance viewer is displayed and the Update buttons are enabled, as they should be. Notice that the navigation buttons are also enabled, which might not seem correct. Given that you just set the DeactivateTargetOnHide property to TRUE and there is no Navigation-Target on Page 2, you might expect that the navigation buttons would be disabled when you select Page 2. What happens, however, is that the toolbar code detects that there is an object on Page 2 that is a Data-Target of the SDO (on Page 1) that is the Navigation-Target of the toolbar. For this reason the standard behavior is to leave the navigation buttons enabled and allow them to navigate through the Customer records from Page 2 exactly as you could from Page 1. If you want to change this behavior, you can use the DisabledActions toolbar property that is described in the "Disabling and hiding buttons and menu items" section.